COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		This  program  is  for  enciphering  files  in a time-sharing
C00008 00003		3.  The cryptographer should not be able to crack the message
C00013 ENDMK
C⊗;
	This  program  is  for  enciphering  files  in a time-sharing
system in order to ensure privacy.  It is entirely based on the  open
cryptographic literature.

	A running key, which is a string of characters as long as the
message, is generated, and each character of  the  message  is  XORed
with  the  corresponding  character  of  the  running  key  to  get a
character of  the  cryptogram.        If  the  running  key  were  an
equi-distributed  independent  sequence of characters, the cryptogram
would be unbreakable, because the a posteriori probabilities  of  the
various  messages  given  the cryptogram would be the same as their a
priori probabilities.  In this case, the  running  key  would  either
have  to be stored in the file system or it would have to be supplied
by the user each time he used  the  program.    Either  of  these  is
impractical,  so  the  running  key  is  generated by a pseudo-random
process from a starting  key  each  time  a  file  is  enciphered  or
deciphered.   This gives rise to a number of pitfalls that have to be
avoided:

	1. It  is  essential  not  to  encipher  two  files  or  even
successive  versions  of  the  same  file  with the same running key.
Given two files enciphered by the same key, they can be decrypted  by
guessing  successive  characters  of the running key so as to produce
"English"  from  both  cryptograms.   Given  the  statistics  of  the
"English",  the process can be automated. We avoid this difficulty by
incorporating the time  as  read  from  the  computer  clock  in  the
starting  key so that even if the same nominal key is used twice, the
actual starting keys and so the running keys will be different.   The
time  is  stored in plain text with the file and is combined with the
nominal key supplied by the user for deciphering the file.

	2.    The  cryptographer  will  often  be  able  to  guess  a
substantial  part  of  the  cryptogram from his knowledge of what the
user has to say. Our goal is that even if the cryptographer  has  the
whole of the plain-text except a single character, he still will not
be able to get that character.  Even stronger, if the cryptanalyst
guesses the whole file, the cryptogram shouldn't help him confirm or
disconfirm his guess.

	Therefore, we have to avoid the possibility that the cryptographer
will guess a sequence of characters of the message, combine this with a
sequence of characters of the cryptogram to get a sequence of characters
of the running key, and continue the running key by its law of formation.
If the running key were simply the set of numbers produced by one of the
usual random number generators, it would be subject to this method of
attack.  The solution to this problem is to make the running key
uncontinuable.  Thus we would like it to be such that if all the
characters of the running key but one were known, that remaining character
still could not be obtained. Our way of accomplishing this is to use three
congruential random number generators with different moduli.  The
corresponding characters generated by two of them are XORed, and the third
is used to determine which characters of the resulting sequence are used
to make up the running key.

	3.  The cryptographer should not be able to crack the message
simply by trying nominal keys in turn using a digital computer.  This
requires that the nominal keys be selected from  a  population  large
enough  so  that  it can't be scanned in an amount of work reasonable
for the cryptographer.  We leave this up to the user.  He provides  a
sequence  of  characters  of  arbitrary  length.        Even  if  the
cryptographer  has  parallel  very  high  speed  computing  equipment
designed  for the purpose, a population of 10↑15 potential keys seems
adequate and could be supplied by a 15 digit randomly chosen  nominal
key.      In  compensation  for  the  labor  of memorizing a 15 digit
sequence, the user can use the same nominal key on all  his  messages
without  danger  of  repeating  the same starting key provided no two
messages are enciphered at the same time.

			The algorithm

	This is the basic algorithm used in  the  programs  CODE.SAI,
ENCODE.SAI,  and DECODE.SAI, written by R. E. Gorin and M. J. Waters.
The two latter programs use double precision arithmetic contained  in
a  subsidiary  Fail  program  called  DBLP.    The first program is a
simplified single precision version which does  not  incorporate  the
time into the key, making encoding and decoding identical.

Let  the  three  congruential  random  number  generators  be   calld
Ran1,Ran2,Ran3  where the next number generated by Ran1 is x1*x2 +x3,
by Ran2 is x4*x5+x6 etc.  Thus we have initial parameters  x1  throuh
x9.

1.  Initialization of parameters: The user's key is concatinated with
the  time in milliseconds since midnight to produce a new key.  Let c
be the ascii representation of the first  character  in  the  nominal
key.   If 141≤c≤172 set c=c-40. Let p be the c th prime, q the c+64th
prime.For each xi replace xi by p*xi+q.  This procedure  is  repeated
for each character in the nominal key.

2.The running key is generated s follows:       The first 66 elements
of  Ran1  are used to initialize an array Tab.       The next element
X7 of ran 3 is generated.  This is shifted right 5 bits to reduce its
magnitude.  Let  count be (x7 land 15)lor 4). The following loop will
be repeated count times.(land is logical and;lor is logical or)  This
insures that count is ≡1 mod 4.          Generate x4. Obtain A,the x4
mod 67 th entry of TAB. Generate x1 and exchange this with the  table
entry.    Repeat  this  step  to  obtain  A1.   Form  a  new  word by
concatinating the middle of A and A1.If the count is  exhausted  this
new  word  is  the  next word of the runnng key. If not decrement the
count and repeat this procedure.